Identity-Based Internet Protocol Network

The Identity-Based Internet Protocol (IBIP) Network project is experimenting with a new enterprise oriented network architecture using standard IP version 6 protocol to encode user and host identity (ID) information into the IP address. Our motivation is to increase our security posture by leveraging identity, reducing our threat exposure, enhancing situational understanding of our environment, and simplifying network operations. Our current implementation plan uses credentials from the Common Access Card (CAC) to establish a 40-bit user ID and credentials stored on the computer's Trusted Platform Module (TPM) to establish a 40-bit host ID. The remaining part of the IP address can be a standard (/48) network prefix or support a (/32) prefix and a 16-bit group tag. A registration process (built on top of an 802.1x security framework) then occurs between the host and a registration server (which is currently an enhanced RADIUS server). The IBIP registration server then validates the credentials and automatically configures the edge router, fronting the host, with appropriate access privileges so that no IP address spoofing (or impersonation) is permitted. Hosts that are client machines do not have their IP addresses advertised across the network basically making them unreachable or hidden from reconnaissance initiated by other clients. Servers have their IP addresses advertised as usual. A unique IPv6 extension header was conceived to enable return traffic to hidden clients. This approach will also provide support for approved peer-to-peer applications which may have hidden clients at both ends (voice-over-IP phones, for example). All infrastructure devices (routers, switches, DNS, DHCP, and other designated servers) are also not directly accessible by end user machines. For servers, the user ID is replaced with a service ID which can be used to identify and enforce policies on what the server is permitted to do. For example, if the server policy is to function only as a web server, access control implemented on the edge router in front of that server would only permit web transactions from entering the network. Attempts to use other non-approved applications such as telnet or ssh can be explicitly blocked or monitored and reported. These access controls are created and deployed from the IBIP registration server without human intervention, reducing the likelihood of human error while simplifying configuration and training. All policy violations are also reported via syslog messaging (using existing infrastructure devices) which enhance situational understanding. In summary, this network architecture hides a majority of the machines and infrastructure devices from unapproved access, enforces strong ubiquitous authentication for both host and user, enables enforceable authorization policies, simplifies the Manuscript received April 6, 2012. This work was supported in part by the U.S. Army Contract No. W15P7-12-C-F600. G. Nakamoto is with the MITRE Corporation, Bedford, MA, USA 01730 (781-271-3032; fax: 781-271-2423; email [email protected]) R. Durst is with the MITRE Corporation, McLean, VA, USA 22102 (703983-7535; fax: 703-983-7142; email [email protected] ) All other authors are also with the MITRE Corporation. configuration of routers, and provides improved situational understanding.